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stored at or near the end of the partition. Familiar or novel 
image formats may be used. By storing one or more partition 
images in the imaged partition, the invention eliminates 
consumer confusion between bootable partition size and 
disk size, without sacrificing the advantages provided by 
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STORING A COMPUTER DISK IMAGE storage devices and related concepts such as cylinders, 

WITHIN AN IMAGED PARTITION sectors, platters, tracks, heads, physical sector addresses, 

and logical sector addresses are generally familiar in the an. 

RELATED APPUCAnONS For instance, they are discussed in U.S. Pat. Nos. 5,675,769 

,. . - . . . , . S and 5,706,472 assigned to PowerQuest Corporation, and 

Tic present application claims prioaty to and moorpo- discussions arc incoiporated herein by this reference, 

rates by reference commonly owned U.S. provisional patent ^ ... . , 

application serial No. 60/188.671 filed Mar. 11. 2000 ^. ^ °P««tmE system manages access, not only to the 

disks, but to other computer resources as well. Resources 

FIELD OF THE INVENTION typically managed by the operating system include one or 

10 more disks and disk drives, memory (RAM and/or ROM), 

Hie present invention relates to storing and recovering microprocessors, and VO devices such as a keyboard, 

computer disk images in a computer partition. More mouse, screen, printer, tape drive, modem, serial port, par- 

particularly, the invention provides tools and techniques for allel port, or network port. 

placing images in the same partition that is being imaged, ^any disks mold the available space into one or more 

and for extracting information from images stored in the 15 partitions by using a partition table located on the disk. A 

imaged partition, thereby allowing single large partitions to wide variety of partition types are used, and more partition 

be used more effectively. types will no doubt be defined over time. A partial list of 

Tcr^uMTr-AT TJAnvr-DriTTivm nu ™c current partitions and their associated file systems is given in 

TECHNICAL BACKGROUND OF THE y.S. patent appUcation Ser. No. 08/834,004 and incorpo- 

INVENTION 20 rated here by reference. The list includes a variety of 12-bit, 

t r" 11 16-bit, and 32-bit FAT file systems and numerous other file 

computers Generally systems. Tools and techniques for manipulating FAT and 

Cbmputer hard disks and other computer storage devices certain other partitions are described in U.S. Pat. Nos. 

hold digital data which represents numbers, names, dates, 5,675,769 and 5,706,472 assigned to PowerQuest 

text, pictures, sounds and other information used by ^ Corporation, incorporated herein by this reference, 

businesses, individuals, government agencies, and others. To One partition table composition, denoted herein as the 

help organize the data, and for technical reasons, many "IBM-compatible" partition table, is found on the disks used 

computers divide the data into drives, partitions, directories, in many IBM® personal computers and IBM-compatible 

and files. The terms "file*' and "directory*' are familiar to computers (IBM is a registered trademark of International 

most computer users, and most people agree on their mean- Business Machines Corporation). Although IBM is not the 

ing even though the details of written definitioas vary. only present source of personal computers, server 

However, the terms "partition" and "drive" have different computers, and computer operating systems and/or file 

meanings even when the context is limited to computers. system software, the term "IBM-compatible" is widely used 

According to some definitions, a partition is necessarily in the industry to distinguish certain computer systems from 

limited to one storage device, but a "file system" may o^er computer systems such as Macintosh computer sys- 

include one or more partitions, on one or more disks. Many t^ms produced by Apple Computer (Macintosh is a market 

partitions reside on a single disk, but some approaches, such of Apple Computer) and UNIX computer systems. IBM- 

as volume sets, stripe sets, minor sets, and others, store a compatible partition tables may be used on a wide variety of 

single partition's data on more than one disk. disks, with a variety of partition and file system types, in a 

As used here, a "partition** is a region on one or more variety of ways, 
storage devices which is (or can be) formatted to contain one ^ shown in U.S. Pat. Nos. 5,675,769 and 5,706,472, one 
or more files or directories. A partition may be empty. A version of an IBM-compatible partition table includes an 
partition may also be in active use even without any Initial Program Loader ("IPL**) identifier, four primary par- 
directories, file allocation tables, bitmaps, or similar file 45 tition identifiers, and a boot identifier. As also shown in those 
system structures if it holds a stream or block of raw data. patents, each partition identifier includes a boot indicator to 
Each formatted partition is tailored to a particular type of file indicate whether the partition in question is bootable. At 
system, such as the Macintosh file system, SunOS file most one of the partitions in the set of partitions defined by 
system (a variant of the UNIX file system), Linux file system the partition table is bootable at any given time. 
(EXTZfs, a variant of the UNIX file system), Windows NT 50 Each partition identifier also includes a starting address, 
File System ("NTFS"), NetWare file system, Linux file which is the physical sector address of the first sector in the 
system, or one of the MS -DOS /FAT file systems. partition in question, and an ending address, which is the 
(MACINTOSH is a trademark of Apple Computer, Inc.; physical sector address of the last sector in the partition. A 
SunOS is a trademark of Sun Microsystems, Inc.; WIN- sector count holds the total number of disk sectors in the 
DOWS NT and MS-DOS are trademarks of Microsoft 55 partition. A boot sector address holds the logical sector 
Corporation; NETWARE is a trademark of Novell, Inc.; address corresponding to the physical starting address. 
LINUX is a mark of Linus Torvalds). Some IBM-compatible computer systems allow "logical 

Computers utilize a wide variety of storage devices as partitions" as well as the primary partitions just described, 
storage media, for user data. Storage technologies currently All logical partitions are contained within one primary 
provide removable optical, and magnetic disks, fixed and 60 partition; a primary partition which contains logical parti- 
removable hard disks, floppy disks, solid state storage tions is also known as an "extended partition." 
devices, and new storage technologies are continually being Each partition identifier also includes a system indicator, 
actively researched and developed. Indeed, some storage The system indicator identifies the type of file system 
devices used by computers in the future may be cubical or contained in the partition, which in turn defines the physical 
some other shape with no moving parts rather than flat and 65 arrangement of data that is stored in the partition on the disk, 
circular, and in addition, storage devices which use com- Values not recognized by a particular operating system are 
puter chips as storage media are being developed. Disks, treated as designating an unknown file system. The file 
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system associated with a specific partition of the disk restored, including all system and user data, including dislc 

determines the format in which data is stored in the partition, partitions, operating systems information, user files, and 

namely, the physical arrangement of user data and of file boot sector data. A sector-by-sector image preserves 

system structures in the portion of the disk that is delimited optimizations, producing an exact image of the disk, with 

by the starling address and the ending address of the S the exception that some images do not contain data from 

partition in question. At any given time, each partition thus unallocated sectors. 

contains at most one type of file system. The imaging approach facihtates sequential head moves 

across the disk platters in so-called "elevator seeks", thereby 

Data Backup Approaches decreasing both the time needed to backup or restore entire 

partitions and/or disks, and decreasing the chance of a head 

Many computers arc sold with opcratmg systems, appli- crash.Imagingof the type shown in HG. 2 can be performed 

cation programs, and other data already loaded on the disk. using the Drive Image product which is commercially 

Manufacturers and vendors of computers often would like to available from PowerQuest Corporation of Orem, Utah 

provide users with a backup or image of the information they (DRIVE IMAGE is a registered trademark of PowerQuest). 

originaUy loaded on a hard drive. Two basic approaches are with either the file-oriented approach shown in FIG. 1 or 

used in conventional systems and methods to backup com- the sector imaging approach shown in FIG. 2, the backup 

puter data. One approach is generally file-oriented, while die medium 106 may be a disk containing a target partition other 

other approach deals with files but operates primarily on than the partition 100. The target partition may or may not 

clusters, sectors, runs, or similar logical aUocation units the partition 100; the partition 100 and the target partition 

which are smaller than files. ^ay be on the same disk, or they may be on two disks on the 

A file-oriented backup approach is illustrated in FIG. 1. A same computer. The source and target computers may also 

partition 100 includes system data 102 and user data 104. be connected by a network link, as when the target partition 

The system data 102 includes file system data such as sector is directly attached to a network server to receive backup 

or cluster allocation maps or tables and directories. The images of partitions 100 on clients of the server, 

system data 102 also includes operating system data such as ^ One backup method according to FIG. 2 involves two 

partition tables and boot code. The user data 104 includes partitions on a drive. The first partition is the source partition 

data created by users, such as word processor or spreadsheet 100, which contains all tiie user programs and data 104, 

files, as well as appHcation programs, dynamic libraries, and while the target partition is separate partition 106 on the 

other data which is loaded by tiie vendor or system integrator same drive; the partition 106 often contains little or nothing 

and organized in tiie partition by the file system structures. more than an image of tiie first partition 100. For example, 

As shown, this backup approach copies the user data 104 to a 10 GB hard drive might contain two partitions, namely, an 

a backup medium 106, such as a ZIP disk (mark of Iomega), g GB partition 100 with tiie system files and pre-installed 

a tape drive, a writable CD, a WORM drive, or a collection software and a 2 GB partition 106 tiiat contains a disk image 

of floppy disks. of the partition 100. 

Witii such a file-by-file backup, each file is backed up 35 However, manufacturers are sometimes reluctant to 
separately, and can be recovered separately. This can be divide disk drives into more than one partition, because 
advantageous. However, file-oriented approaches also have some computer purchasers equate the size of their main 
some disadvantages. File-by-file backup programs access partition (for instance, the so-called "C: drive" on many 
tiie user data 104 through standard operating system and/or IBM-compatible computers) with tiie size of tiie entire disk, 
file system routines, and they require tiiat the operating If the primary partition on a new disk drive is substantially 
system and file system software be reinstalled prior to smaller than the advertised disk size, purchasers may con- 
system recovery. They may miss important files such as elude that tiie disk drive itself is smaller tiian tiiey requested, 
registry or system configuration files, and they do not back In the example above, a user might erroneously conclude 
up data 104 from deleted files even if tiie sector(s) holding that tiie computer came witii an 8 GB drive rather than the 
tiie data have not been overwritten. In addition, a single file 45 expected 10 GB drive, because the bootable partition 100 
may be stored in a series of clusters at locations scattered contains only 8 GB. This mistaken but understandable 
across the disk. To restore such a file, the disk head must be conclusion leads to consumer dissatisfaction and increases 
randomly positioned multiple times across the platter, which the vendor's support costs. 

increases restoration time and increases tiie chance of a disk Another problem facing the computer user is how to 

head crash. 5q acquire a fully functional backup of both system and user 

FIG. 2 shows an imaging approach which also restores data. Many critical system files, such as the registry files 

files but deals primarily in clusters or another file allocation which contain critical configuration information, are open 

unit which is typically smaller than a file. Unhke tiie when a computer is running in tiie Microsoft Windows 95, 

file-oriented backup shown in FIG. 1, the imaging backup Windows 98, and Windows NT operating systems. Even if 

approach shown in FIG. 2 copies the entire disk state. An 55 an approach like that shown in FIG. 2 is used, tiiese open 

image may be created on the backup medium 106 by reading files cannot be successfully saved by standard backup soft- 

and writing each sector, in order, in one or more partitions ware. If a computer's hard disk crashes and all files must be 

100 of a disk. Usually unallocated sectors are skipped. rebuilt, some user files 104 can be restored. But the oper- 

This imaging approach can backup all data 102, 104, ating system, device drivers, and perhaps even the backup 

including data in deleted files when that data has not been 60 software itself, all must be reinstalled from some source 

overwritten, file system structures, operating system files, otiier than the image 106. Data files that were open when the 

device drivers, information about network cards and other backup was made also would not be restored from the image 

installed hardware, application programs, user-created files, 106. 

hidden files, and all other data 102, 104 stored in the selected Accordingly, it would be an advancement in the art to 

partition(s) 100. Some imaging approaches also copy par- 65 provide improved data backup tools and techniques, includ- 

tition table information to the backup medium 106. When a ing tools and techniques for avoiding consumer confusion 

full disk image is restored, every byte of the original disk is about disk size while still providing backup images. 
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Such improved tools and techniques are disclosed and 
claimed herein. 

BRIEF SUMMARY OF THE INVENTION 

The present invention provides tools and techniques for ^ 
storing and retrieving data images of a partition within the 
imaged partition. As used here, "in-partition images" are 
images of a partition stored withia the imaged partition. An 
image created in the factory before delivery to the user (a 
factory image) as well as one or more user-updateable 
images can be stored in the same partition. The in-partition 
images themselves may be compressed, or not compressed, 
packed or not packed, and/or encrypted or unencrypted. The 
in-partition images may be stored as one or more files within 
the file system, or as an image container. If the image file 
would be larger than the maximum file size allowed for a 
particular operating system, (often 2 GB) the image may be 
divided into multiple files that together make up all or part 
of the container. The image may also be divided into 
multiple files to facilitate later transfer to multiple smaller 
storage media, such as writable removable media. To speed 
restoration time and to assist recovery, the image may be 
stored contiguously at or near the end of the partition, but is 
not restricted to either being contiguous or at the end of the 
partition. For improved efficiency, the image file or image ^ 
container can be stored in a separate subdirectory of the 
imaged partition. 

In one embodiment, creation of an image within a parti- 
tion creates an exact copy of the entire partition, including 
deleted but not overwritten files. Each sector of the partition, 
in order, is read into the image. The image must be created 
when the computer has been put into a state that allows 
exclusive disk access. This prevents inconsistencies in the 
data and helps ensure that system files such as the Microsoft 35 
Windows registry are closed and thus can be imaged. When 
the image is made of the partition, the image itself is not 
imaged. However, user images may be incrementally 
updated. 

If more than one image is stored on a single partition, a 40 
user can choose which image should be used to restore the 
partition. If the disk or its partition is damaged, it may still 
be possible to recover the imaged data. Copies of a portion 
of the partition data and/or the system data sufficient to 
recover the imaged partition can be stored at a specified 45 
location within the imaged partition, within the image 
container, in a separate diagnostic and recovery partition, 
and/or on a removable recovery medium such as a ZIP drive, 
a floppy disk, and so on. Which system files or other data 
should be saved depends both on the operating system 50 
involved and the nature of the image. Using the saved 
system data, the image can then be located on the partition 
and restored. The image files and/or image container may 
also contain unique signature bytes to allow them to be 
detected by scanning the storage medium. In this way, if the 55 
disk or partition is damaged, the image may be discovered 
and used to restore the partition. 

In one embodiment the file system data is verified when 
it is used, such as before an image is created or updated, after 
an image is created or updated, and when system data is 60 
stored in a separate location such as in a recovery disk or in 
a diagnostic and recovery partition. The consistency and 
integrity of the image itself is also verified when used, such 
as after it is created or updated, and before and after it has 
been used to restore user data. This can be performed by way 65 
of check codes such as checksums or CRC codes embedded 
in the image files and/or the image container. 
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The image can be restored to a number of locations, 
including target locations inside the same partition that 
contains the image, another partition on the same machine, 
another partition on a physically different machine (such as 
over a network connection), or onto a removable medium. 
One or more files from the image can be individually 
restored without restoring the entire image. Other features 
and advantages of the present invention will become more 
fiilly apparent through the following description. 

BRIEF DESCRIPTION OF THE DRAWINGS 

To illustrate the manner in which the advantages and 
features of the invention are obtained, a more particular 
description of the invention will be given with reference to 
the attached drawings. These drawings only illustrate 
selected aspects of the invention and thus do not limit the 
invention's scope. In the drawings: 

FIG. 1 is a diagram illustrating a conventional file- 
oriented backup approach which copies \iser data from a 
partition to a different medium. 

FIG. 2 is a diagram illustrating a conventional imaging 
approach which copies user data and file system data from 
a source partition to a different medium and/or a destination 
partition. 

FIG. 3 is a diagram illustrating an approach according to 
the present invention, which copies user data and file system 
data in at least one direction between an imaged partition 
and an image stored in that partition. 

FIG. 4 is a diagram illustrating an imaged partition which 
uses a FAT file system and is configured according to the 
invention. 

FIG. 5 is a diagram illustrating an imaged partition which 
uses an NTFS file system and is configured according to the 
invention. 

FIG. 6 is a diagram illustrating a computer system accord- 
ing to the invention. 

FIG. 7 is a flowchart illustrating methods according to the 
invention. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

The present invention relates to computer systems, 
methods, and configured storage media for storing images 
onto an imaged partition and for later recovering the images, 
that is, using them to restore imaged data. The invention is 
illustrated generally in FIG, 3. Unlike the conventional 
imaged partition 100 of FIG. 2, the novel imaged partition 
300 includes one or more images 302 of data 102, 104 from 
the imaged partition 300. The images 302 are created using 
sector-by-sector or cluster-by-cluster imaging tools and 
techniques, which may be those already known or those 
hereafter developed. However, some embodiments allow 
users to select specific subdirectories and/or specific files 
when creating or restoring an image 302. 

The problem of consumer confusion between the size of 
a bootable partition and the size of a disk is avoided, because 
a separate partition is not needed to hold the image. The 
bootable partition seen by the user is substantially the same 
size as the disk. A small separate partition may be used, in 
some embodiments, to hold information used to locate the 
image(s) in the imaged partition 300 after system data 102 
is damaged. But even in this case consumer confusion is 
unlikely because the difference in the size of the bootable 
partition 300 with the separate partition and the size without 
the separate partition is at most a few megabytes (minimum 
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partition sizes are imposed by file system and other system known at boot time. For instance, a Master Boot Record 

constraints). Thus, on a typical disk of gigabyte or greater ("MBR'*) stored at a fixed location on the disk contains the 

capacity the bootable partition 300 can be made sufficiently "bootstrap** program that initially gets the computer up and 

close in size to the size of the entire disk to alleviate running. System data 402, 502 may also be stored at 
consumer concerns. 5 locations whidi are not hard-wired. System data 402, 502, 

whether hard-wired or not, are generally familiar in the art. 

Operating Systems and File Systems Generally But the use and imaging of system data 402, 502 according 

Each partition 300 resides on a computer using at least present invention are novel, 
one specific type of operating system, and each partition 300 System data 402, 502 include both data 404, 504 which is 
may have its own type of file system. The present invention specific to a given file system and data such as the partition 
is illustrated mainly by reference to MS-DOS or Windows table 406, 506 which is not file-system-speciflc. The parti- 
operating systems and FAT or Windows NT file systems. tion table 406, 506 for a given computer may be stored 
However, those of skill in the art win appreciate that the outside a given partition 408, 508. The file-system-specific 
scope of the present invention comprises the creation and/or system data 404, 504 are stored inside the partition 408, 508. 
use of images 302 stored in imaged partitions 300 using a As noted above, the partition tables 406, 506 define the 
UNIX-like file system (namely, Linux, BSD, System V, partitions, while the file-system-specific system data 404, 
SunOS, and/or other UNIX file systems), or operating 504 define the files within the partition 408, 508. 
systems and file systems of various other types. in the illustrated FAT configuration 400, the file system 

To allow creation of an image 302, the operating system data 404 includes at least a file allocation table 410 and a 
must allow exclusive file access, or else be able to defer to ^ root directory 412. The file allocation table 410 contains 

another operating system that itself allows exclusive file entries for space which is allocated within a space 414 

access. This can be accomplished by an operating system managed by the FAT file system; the file allocation table 410 

that maintains a single-threaded environment or by one that entries specify which clusters are allocated to each file 416 

provides filesystem locking and hence allows exclusive in the managed space 414. The root directory 412 contains 
access. For example, the MSDOS operating system provides ^ entries that describe the names and hierarchical position of 

exclusive file access because it is a single -threaded file system directories, subdirectories, and files 416. The 

environment, at least from an application program's per- files 416 may include executable files, user-created files, 

spective. One could also use a Linux (or another UNIX-Uke) special files used to run programs such as .dU files, sound 

operating system and utilize system locks to provide for files such as .wav files, and so on. Storage space not 

exclusive access. While the Windows (currently Windows allocated to any file 416 is fi-ee space 418. 

95, 98, NT and Windows 2000) operating systems are In the iUustrated NTFS configuration 500, the file system 

multi-threaded, they can defer to MS-DOS, Linux or another data includes several system files 504. The system files 504 

single-threaded environment. An implementing program (also called "metadata files") serve roles in conventional 

according to the invention can begin execution in these systems that are well understood. However, one of the 

multi-threaded environments and then pass control to a differences between FAT and NTFS configurations deserves 

portion that runs in DOS or Linux mode and thus provides repeating. As shown, FAT file systems make a strong dis- 

exclusive file access. Some operating systems also provide tinction between a file system area 404 and a user data area 

locks that ensure exclusive file access, or provide exclusive 414. pAT file system structures, such as directories and disk 

access at subsystem load time before caching and virtual allocation structures, are stored in the system area 404 while 

memory are enabled, so deferral to another (single -threaded) appUcation programs, documents, and other user files are 

operating system is not needed. stored in the user data area 414. By contrast, NTFS stores all 

^^rr. ^ ,.t™« ^ * data in files, including not only user data such as application 

FAT and NTFS File System Examples programs 528 or user-generated documents 530 but also file 

FIG. 4 illustrates a computer configuration, indicated 45 system data such as directories 518 and disk allocation 

generally at 400, according to the present invention in a structures (also referred to as bitmaps) 520. 

computer utilizing a FAT file system. FAT file systems Some configurations may mix system data and user data 

include, without Hmitation,FAr-12,FAr-16, and FAr-32 file differenUy. In particular, some may blur the line between 

systems which employ a file allocation table ("FAT'* — hence system data and user data, and some may treat a given piece 
the name "FAT file system"). FAT file systems are well 5Q of data as system data while others treat the same or 

Icnown. analogous data as user data. Even in the FAT and NTFS 

FIG. 5 illustrates a computer configuration, indicated configurations shown, classification problems may arise. For 

generally at 500, according to the present invention in a instance, one might ask whether registry information and 

computer utilizing an NTFS file system. Discussions of system configuration information should be classified as 
NTFS are provided in "Inside the Windows NT File 55 system data or user data. However, an image 420 generally 

System**, by Helen Custer, ISBN 1-5561 5 -660- X, as well as contains both system and user data rather than user data 

in marketing and technical materials available in hard copy alone, to reduce or avoid the need to reinstall system 

and on the Intemet from Microsoft Corporation and other information when recovering a partition with data from the 

sources. image. 

In the illustrated configurations 400, 500, and in other 60 t tv 

configurations according to the invention, some locations on mage ypes 

disk are reserved in that they are used to control the basic The images 420 used according to this invention may be 

operation of the computer, as opposed to controlUng a compressed, or not compressed, packed or not packed, 

specific application program or a specific operating system and/or encrypted or unencrypted. Compression modifies 
Ubrary. These special locations store certain types of system 65 system data 102 and/or user data 104 by replacing selected 

data 402, 502, and they are generally "hard-wired" into the data elements with more compact representations through 

computer system, in the sense that their disk locations are redundancy-removal techniques such as run-length 
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encoding, data dictionary use, and the like. Packing removes 
some or all of the miused space in file allocation units, such 
as by omitting from an image 420 copies of entirely unused 
sectors at the end of a cluster. Encryption modifies data in 
order to keep the meaning of the data hidden firom unau- 
thorized persons. Those of skill in the computing arts 
understand how to use familiar took and techniques to 
encrypt, compress, and/or pack an image 420 in the present 
context. 

The images 420 may also be stored contiguously or 
non-contiguously. A contiguous image 420 is stored as a 
single block of data. By knowing the location of the initial 
sector and knowing either the length of the image 420 or the 
marker that signals the end of the image 420, an implement- 
ing program can read the entire image 420 by beginning at 
the first location and then continuing to read each sector until 
the end of the image 420. By contrast, a non-contiguous 
image 420 is stored in at least two, and possibly many more 
separate locations on the disk with non-image data and/or 
free space located between the pieces of the image 420. If 
the image 420 is stored as a non-contiguous file, then at least 
a portion of the file system data must be accessed to read the 
image 420 (although not necessarily by readmg the same 
copy of file system data that is used by the operating system 
and applications during normal operation). The parts of the 
non-continuous image file can be accessed in the event of a 
file system failure. This access information can be provided 
in a specified location within the imaged partition, in the 
image container, or in a separate diagnostic and recovery 
partition. 

For convenience, this discussion generally speaks of an 
image 420 which is stored in an imaged partition such as the 
partition 408 or 508 on a disk. However, the partition in 
question may hold several images 420. The partition and the 
image(s) 420 may be stored on several disks through fault 
tolerance measures. The storage medium may also be some- 
thing other than a disk, such as a CD-ROM, chip memory, 
or other computer storage medium, including media devel- 
oped hereafter but configured or utilized according to the 
present invention. 

An image 420 may be either a user-generated image 422 
or a factory-generated image 424. A user image 422 is an 
image of a machine's partition(s) generated after the 
machine has been delivered to the user. The user will often 
have added user data 104 and system data 102 to data placed 
on disk by the "factory (Le., by an OEM, system integrator, 
reseller and/or corporate Information Technology depart- 
ment or the like). For instance, the user may have installed 
additional programs. The user may also have removed data 
that was installed by the factory. Some embodiments of the 
invention permit user images 422 to be incrementally 
updated. 

By contrast, a factory image 424 is an image of the data 
created by the manufacturer or other vendor/provider. A 
factory image 424 contains a copy of the machme's disk, 
including all factory installed software and system files, 
before the user starts to use the machine. Embodiments of 
the invention do not generally support incremental updates 
to a factory image. 

An image 420 may be stored either as an image file 532 
or within an image container 534. Containers 534 are used 
because, in some environments, there is an upper limit on 
file size which makes single files too small to hold desired 
images. For example, in some FAT file systems files cannot 
be larger than 2 GB. To store an image 420 that would be too 
large for a single file, the image 420 is divided into two or 
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more pieces and each piece is stored in a file that does not 
exceed the maximum file size. The files that hold the image 
420 collectively form the container 534. A given container 
may have no contiguity (noncontiguous files stored apart 
from each other), partial contiguity (contiguous files stored 
apart from each other), or fuU contiguity (contiguous files 
stored next to each other). In addition, an image container 
may contain more than one image. In one embodiment, the 
image container includes image files and additional control 
files; in other embodiments, image contents and control data 
are not necessarily stored in separate files. Within the control 
files are such things as an image Table of Contents (TOC), 
check codes, a copy of system data for the partition, and 
unique signature bytes for identification. If a container that 
holds two or more images is partially corrupted, but an 
image within the container is intact, then that image's 
signatures and/or checksums can be used to locate the 
image, to verify its intactness, and to allow restoration of the 
image. This may be done despite serious damage to the 
container holding the image and/or to other image(s) in the 
container. 

By way of example, some embodiments use the following 
fully contiguous container format: 
<End of Partition, End of Image Containcr> 
FUe: toc_end.pqc 
Beginning TOC signature 
Container Signature bytes 
Offset to beginning of container 
Number of image directory entries 
Offsets from beginning of file for each image directory 
entry 

Major/minor format (this is the container format ver- 
sion X.Y) 

Unique Partition Signature, checksum and size of con- 
tainer 

Directory entry for image 1 
Image name 

Offset to image (if image is in container) 
Checksum of image 
Size of Image 
Size of image data 

Copy of system data and retrieval information for 
image (in case of partition damage or if image is 
not in the container) 

Creation date/time 
Directory entry for image 2 

Image name 

Creation date/time 

End TOC signature 
File: filenamel.pqi (or multiple files if necessary) 

Image 1 Data (actual image file or files) 
File: interl.pqc (between each image, if three images, next 

file would be inter2.pqc) 

Inter-Image partial TOC (only a TOC entry for the next 
image) 

Inter Container Beginning PTOC Signature bytes 
PTOC Contents . . . 
Directory entry for image 2 

Directory contents (as in image 1 above) 
Inter Container End PTOC Signature bytes 
Filc:filenamc2.pqi (or multiple files if necessary) 
Image 2 Data 

File: toc_begin.pqc (redudant TOC, duplicate of End TOC) 
Beginning TOC signature 
TOC Contents . . . 
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End TOC sigaature management software and multiple operating systems will 

<Beginning of Image Container> be present, allowing a user of the system 600 to choose 

An image 420 may also be stored in a non-contiguous file between several bootable partitions. In such cases, one or 

or container. In some embodiments the block size is equal to more of the bootable partitions may be configured for 

or smaller than the smallest cluster expected. Generally 4K $ in-partition images according to the invention. It is possible, 

should be considered the smallest cluster, even though in but not necessary, for every primary or logical partition on 

some implementations, a clxister size as small as 2K may be a given system to be configured with respective in-partition 

assumed. In some embodimeats every block contains the images. 

following header information: In some embodiments a relatively small diagnostic and 

the file ID or unique image identifier which identifies recovery partition 612 is also present and defined in the 

which file the block belongs to partition table 608. As explained below, this diagnostic and 

the sequential ID which identifies each block's sequence recovery partition 612 can be used for recovery if the imaged 

number primary partition 610 is damaged. Because disk crashes, 

the checksum which is used to verify the contents of the ^"^'^^ similar trauina sometimes damage only 

block and 15 ^® system data m the bootable prunary partition 610, 

the *ma *e data recovery can be facilitated by storing a copy of the system 

ThV^riouslmage 420 characteristics just described may f^'^^""^ location information for retrieval of images 420 in 

be combined in various ways. For instance, a FAT partition ^he diagnostic and recovery parUtion 612. 

may hold a factory image stored in a contiguous container Th^ imaged partition 610 mcludes user data 614 and file 

and an incremental user image stored in a non^ntiguous 20 ^y^^em data 616. If the imaged partition 610 is a FAT 

file; an NTTS partition may hold factory and user images P^^^^ion as shown m HG. 4 then the user data 614 and file 

stored in contiguous and/or non-contiguous files and/or system data 616 are organized as FAT user dat^^^^^ 

containers; images may be stored in HPFS or Linux parti- ^X^^"^ ^^^^ ^^^^ ^he unaged parUtion 610 is an NTTS 

tions; and so on. Various internal container and file formats Partition as shown in ¥IG. 5, then theuscr data 614 and file 

may also be used, with or without various famihar elements 25 ""'^ organized as NTFS user data 526 and 

such as checksums, long file names, and tiie like. NTFS file system data 502. When other file systems are 

One of the benefits of contiguity in images according to ^sed, the user data 614 and file system data 616 are 

the invention is that data can sometimes be recovered even orgamzed accordingly. 

if there is a physical head crash. These crashes usually occur Th« imaged partition 610 also includes at least one image 

in the early sectors of a drive where the FAT table and other 30 420 containing a copy of at least some of tiie user data 614. 

system data are often stored, while the image is stored in a Note that even though the same data thus appears in at least 

rarely accessed part of the partition which is less likely to be two places in the partition 610, Uie data 614 outside the 

damaged. image 420 is directiy usable by conventional operating 

Another benefit is minimized data movement when the system and/or apptications software while the copy in the 
image is restored. If the image 420 is placed at a known 35 image 420 is not. User data 614 outside the image 420 is 
location, such as the end of tiie partition 300, tiien even if directiy accessible to the operating system or appUcation 
FAT, NTFS, or other system information is lost, recovery programs, through the file system, because it is stored in a 
may still be complete. The image 420 can be located by its format assumed by that conventional operating system soft- 
position (for example, at eitiier the beginning or the end of ware. By contrast, the copy within the image 420 is stored 
tiie partition 300), and if the image 420 hasn't been cor- 40 by a program implementing the invention in an internal 
rupted or damaged, it can tiien be read to restore data that format unknown to most or aU file systems, operating 
would otherwise be lost. systems, and conventional applications. For instance, the 

copy of user data inside the image will generally be 

Computer Systems Generally compressed, packed, and/or encrypted, making the data 

FIG. 6 illustrates a computer system 600 according to the 45 unusable by most software until the implementing program 

present invention. The system 600 contains at least one decompresses, unpacks, and/or decrypts the data, and lays it 

processor 602, internal memory 604 such as random access back down in a conventional file system format, 

memory (RAM), and persistent storage 606. Suitable gen- Note that in some cases the only copy of particular user 

eral or specific purpose processors 602, memories 604, data will be in the image 420. For instance, the following 

persistent storage media 606, and supporting circuitry (e.g., 50 sequence of events might occur. The vendor installs the 

buses, clocks, I/O) and software (e.g., device drivers, file operating system and applications in the partition 610. The 

systems, operating systems), including those commercially vendor also creates an image 424 of the partition 610 and 

available and tiiose yet to be developed, may be configured stores the factory image 424 in the partition 610. The user 

for in-partition images by persons of skill in the art accord- receives the system 600 and begins using it. Then some user 

ing to tiie teachings herein. 55 data 614 is lost through a virus attack, user error, overwriting 

A partition table 608, such as an IBM-compatible parti- during installation of other software, or another event. At 

tion table of the type noted in the Technical Backgroimd, this point, the only copy of the lost data in the partition 610 

defines at least one partition 610 in the persistent storage is the copy in the factory image 424. Similarly, the onJy copy 

606. Other system data, such as boot record data, may also of certain user data at a given point in time might be the copy 

be present. As used herein, "data" includes spreadsheets, eo in a user-generated image 422. In short, the images 420 are 

word processor output, graphics files, and other documents, not "in-partition images" simply because they are images of 

as well as executable instructions such as machine language, some partition stored in some partition. Nor are tiiey 

microcode, assembly language instructions, portable byte in-partition images because they (may) contain a copy of 

codes, job control language, scripts, interprctable source user data which is stored in standard file system format 

code, object code, linked code, and/or combinations thereof. 65 elsewhere in the partition containing the image. 

The partition 610 will often be the only bootable primary Rather, an image 420 is an in-partition image at least 

partition on the system 600, but in some embodiments boot because it contains user data which came, at some point in 
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time, from the partition 300 that currently contains the image (sector or chister addresses) are embedded in the image 420 

420. In some embodiments, an in-partition image 420 is an itself This embedding approach has the disadvantage that it 

image which is created from a partition and then stored in is not compatible with widely used image formats such as 

that partition without any intermediate storage in another the PowerQuest Drive Image® image container format. Yet 

partition or on another persistent storage medium. 5 another embodiment might place such retrieval information 

If there are two or more images 420 in the imaged in the diagnostic and recovery partition, a specific location 

partition 610, then the images 420 may include a factory on the disk, or in the image container, 

image 424 and one or more end-user images 422. The The images 420 may be stored in predefined locations 

configuration with one end-user image 422 and one factory within the partition 300, with one preferred location being at 

image 424 shown in FIG. 6 is just one example of the many 10 the end of the partition 300. If this location is used, the image 

possible embodiments. 420 will be easier to find after a disk crash. For instance, 

suppose the FAT or Master File Table has been badly 

Image Creator damaged, but the end of the partition 300 can be located, the 

The illustrated system 600 also includes an image creator image 420 is stored contiguously at the end of the partition 

618, Image creation generally is well-known in the art, and 300, and the front of the image 420 is marked with a 

may be readily adapted for use with in-partition images beginning signature value. Then the image 420 can be 

through application of the teachings presented herein. In one located by searching backward from the end of the partition 

embodiment, the image creator 618 initially creates each until the front of the image 420 is located. If the partition 

image 420 but does not update previously created images table 608 has been destroyed and the end of the partition 300 

420. In another embodiment, the image creator 618 also is thus unknown, the search can start at the end of the disk 

updates end-user images 422. A user-defined portion of the or other storage device 606 and work backwards until the 

image 422 can be selectively updated, or a predefined set of front of the image 420 is located. The image 420 can then be 

user files within the image could be updated. The specific iised to restore the lost partition 300, either to the same 

system and user files to be updated could also be defined at storage device 606 if that device still functions, or to another 

the factory when the update is automated, so that the storage medium if necessary. The image could also be 

specified data is updated by imaging it after predefined placed in a image container and found by searching for the 

events and/or at predefined times. container signatures. 

In one embodiment, the image creator 618 creates only Image Lxicator 

factory toages 424. In another embodiment the image ^ creation and image 420 location are closely 
creator 618 creates only _ end-user images 4^^. in otner 

convenience, FIG. 6 shows an imaee locator 620 

emDocmnents, tne same unage creator 61» creates Dotb 

creator 618, but the creation and 

tactory images 4« and end-user images 4^. ^^-^^^^^ ^^^^^^^ ^^j^ performed with overlapping or 
Hie images 420 can be stored in various ways. For interwoven code in a given implementing program. The 
instance, images 420 may be stored contiguously either as a 35 ^^^^ locator 620 is used to locate one or more images 420 
file with adjacent clusters or as a container whose multiple fo, ^j^ta recovery, image updating, image deletion, image 
contiguous files are stored adjacent to one another. Images defragmentation, and similar operations pertinent to 
420 can aLso be stored non-contiguously, in the sense that the in-partition images. If multiple images 420 are found, the 
file(s) used has non-adjacent clusters (or sectors) and/or in ^^^r can choose the image 420 desired, or the image 420 to 
the sense that image files in an image container are not ^^^^^^^ ^^n be automatically chosen by creation date, 
adjacent. name, or some other defining feature. For example, a par- 
Sectors, clusters, and larger image 420 components may tition 300 may contain both a factory image 424 and an 
be grouped in various ways. The image 420 may be stored end-user image 422. To restore data placed on the computer 
as a file, or in a container whose files have some common 600 after the purchase, the end-user image 422 would be 
characteristic such as an extension name or use of another 45 chosen (unless it is inoremental with respect to the factory 
file naming convention. All components of an image could image 424, in which case the factory image 424 would be 
also be stored in the same subdirectory. used first and then the incremental end-user image 422 

If the image 420 is stored as a single contiguous block, would be used), 

then care should be taken to prevent fragmentation by When the partition table 608 and/or the file system data 

utilities such as defragmentation tools and/or partition 50 616 that would otherwise be used to locate an image 420 

manipulation tools. The image file(s) could fragment if a have been damaged, the image locator 620 can be used to 

utility attempts to place all of the free space in a contiguous determine where the image 420 was stored within the 

block. Some utiUtics will slice up one or more large image damaged partition 610. If the image 420 was not stored as 

files and place their pieces into tiie holes near one end of the a contiguous image, recovery will be facilitated if a FAT 

partition, particularly if the partition that holds the image S5 cluster chain or equivalent structure can be found (MFT runs 

420 is resized smaller. If the image 420 is fragmented then in NTFS or inode information in UNIX-like file systems); if 

some implementing programs will report an enor and fail the image 420 was stored in a container then directory 

when data recovery using the image 420 Ls attempted. Other information wiU also be used. As noted, the cluster chain and 

implementing programs merely prefer contiguous images directory information is normally stored in file system data, 

420; although data recovery using tiie fragmented image 420 eo but this retrieval information may be alternatively or addi- 

takes longer, it is still possible with such programs. tionally stored inside the image 420 itself if compatibility 

When images are fragmented, some mechanism must be with the existing Drive Image® format is not reqmred. If 

used to link the fragments together in the proper sequence. compatibility is required, this retrieval information may be 

This mechanism may include the file system data for the stored in the image container or the diagnostic and recovery 

image file(s) involved, and may include file naming con- 65 partition. If an image cannot be found or recovered, because 

ventions for sequencing files in an image container. In the media is irreparably damaged, because the user has 

alternative embodiments, sequence numbers and/or pointers deleted the image file(s) intentionally or inadvertently, or for 



03/19/2004, EAST Version: 1.4.1 



us 6,615365 Bl 

15 16 

Other reasons, then an error is returned, the user is informed, components, functions of the image verifier 622 could be 

and, in some implementations, the program exits. performed in a given implementing program with code that 

One way to implement the image locator 620 is to store overlaps or is interwoven with the code for other 

portions of the system data in a known, fixed location within components, sudi as the image creator 618, image locator 

the imaged partition 300. The copied system data can be S 620, or image restorer 624, 

located, after the normal system data has been lost, by The image verifier 622 may also check the integrity of the 
moving the disk head to the fixed location in question. This contents of an image file by utilizing error checking tech- 
location would normally be marked as system, hidden, and niques such as checksxims, cyclic redundancy checks or 
read-only so it is not easily accessible to the end-user and is other means known to the art. If errors or other exceptional 
not easily deleted or overwritten. Another implementation 10 conditions are detected by the image verifier 622 in any of 
stores the system data needed for image recovery outside the its verifications, then appropriate measures are taken. If an 
imaged partition 300 in a diagnostic and recovery partition error is discovered the verifier 622 may simply report the 
612. Yet another implementation, or a system that could also enor, may attempt to fix the error by itself, or may attempt 
use one of the approaches already mentioned, backs up the to use the image locator 620 and/or image restorer 624 to fix 
necessary system data as recovery information onto a 15 the error. In the case of a fatal error, conditions on the disk 
removable mediixm, such as a Zip drive, a Jaz drive, a 606 that were changed by the implementing program are 
WORM drive, a floppy (or floppies), a tape drive, and so on. restored to the extent possible, a message may be passed to 
In short, the system 600 saves necessary system data such l^e end user (before or after the conditions are restored), and 
as the partition table, boot record, root directory, and file implementing program is terminated, 
allocation table (for FAT systems), Master File Table entries When a diagnostic and recovery partition is used to store 
(for NTFS systems), boot block, super block, bitmap and system data and image location retrieval information, in the 
inode information (for UNIX-like systems) or equivalent event of disruption of the system and/or partition files, then 
structures in other file systems. Thus, the system 600 is able during the startup routine the location of the factory and 
to restore a desired image 420 when the partition table is end-user in-partition images should be verified, and fixed if 
damaged, when the boot record is damaged, when the file ^ necessary, within the diagnostic and recovery partition. The 
allocation table is damaged, when the Master File Table is partition and/or its images could have been moved or resized 
damaged, when the boot block, superblock, bitmap or inode or otherwise altered by a partition-manipulating tool. In such 
information is damaged and when equivalent structures in a situation, the diagnostic and recovery partition should be 
other file systems are damaged. Sometimes an image cannot updated as soon as possible, such as at system boot or 
be found, because of damaged media or for other reasons, start-up time, 
even using all of the backup procedures. In this case, an error 

is retumed, the user is informed, and the program exits. Image Restorer 

Ima e Verifier illustrated system 600 also includes an image restorer 

35 624 which uses a selected image 420 to restore the partition 

An image verifier 622 confirms that the image 420 has not 610 to the state it was in when the image 420 was created, 

been corrupted. In many embodiments, great care is taken by In some implementations, the image restorer 624 will restore 

the image verifier 622 to detect inconsistencies in the file the user data to target locations inside the same partition 610 

system data 616 before an image 420 is created or updated, that contains the image 420. In other implementations, the 

in the file system data 616 after an image 420 is created or 4q image restorer 624 is able to restore the image 420 to another 

updated, in die image 420 itself after it is created or updated, location, such as another partition on the same machine, 

and in the image 420 before and after it has been used to another partition on a physically different machine (e.g., 

restore user data. over a network connection), or a removable medium. 

Images 420 may be modified in various ways, so the If a single partition 300 which stores images 420 as files 

image verifier 622 should perform checks at each point 45 contains both a factory image 424 and a user image 422, 

where a critical assumption about the file system and/or when the image restorer 624 restores the factory image 424 

image data might be incorrect. For instance, the user may it will typicaUy overwrite the user image 422. The user 

create and restore an image 420 using various products, image 422 was not on the partition 300 when the factory 

including the PowerQuest® Drive Image® product. If the image 424 was created, and so the user image 422 will not 

image 420 is stored as a file accessible through the file 50 be restored. On the other hand, if the user image 422 was 

system, the image 420 may be moved. A partition 300 made while the partition 300 contained the factory image 

holding one or more inpartition images may be resized or 424 then a restoration from the user image 422 it will not 

moved, thereby moving or fragmenting the image(s). In such lose the contents of the factory image 424. An image that is 

cases, the software implementing in-partition images must stored in the partition may be overwritten during a restore to 

be notified of the changes or must itself detect them. 55 the partition. If the image is not part of the image being 

The specific tests performed by the image verifier 622 restored, an option must be chosen as to retain the image or 

depend in part on which file system is associated with the not. The default should be to retain the image. If the image 

partition 300. Thus, for a FAT file system, integrity is tested is retained, the directory and aUocation information must be 

by searching for lost clusters, illegal values in the boot modified after the image is restored so that it remains 

sector, or inconsistencies between copies of the file alloca- 60 allocated and in the file system directory structure. An image 

tion table (if multiple copies are present). In general, the lhat is stored in the partition may be included in an image 

image verifier 622 includes checks such as those made by being made of the partition if the image is not in a container, 

the well-known utilities CHKDSK and SCANDISK, as well As noted above, when the system data such as system data 

as checks on images such as those made by PowerQuest 402, 502 has been damaged, the image locator 620 and the 

Drive Image® or other imaging tools. The image verifier 65 image restorer 624 can cooperate to locate and restore an 

622 may also check for image 420 fragmentation and/or image 420 from an image file or container 420. The image 

movement. As with the other implementing program locator 620 finds the location of the image 420 within the 
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partition 300, and the image restorer 624 uses the image 420 image 420 to avoid laying down a corrupt image during a 

to restore the imaged data back onto the partition 300. restoring step 728. 

The determining step 708 determines image storage char- 
Methods Generally acteristics. The determination may be implicit by virtue of 

FIG. 7 illustrates methods of the present invention utiliz- ^ being hard-coded in the implementing program, or it may be 

ing images 420 of an imaged partition 300 within that explidtby virtue of being subject to a configuration file, user 

partition 300. Aspects of these methods have already been selection, or other parameter. The storage characteristics 

discussed in connection with the system 600. Unless clearly determined include whether storage is in an image file 532 

indicated otherwise, the discussion of these methods applies or an image container 534, whether the image 420 is a 

to systems, storage media, and signals according to the ^° factory image 424 or a user image 422, and the degree of 

invention, and the discussions of systems, storage media, contiguousness within the image 420, 

and signals also apply to the inventive methods. If the image 420 is stored at the end of a partition, the 

During an obtaining step 702, an implementing program vacating step 710 relocates aUocated sectors or clusters to 

obtains a copy of user data which is stored in the partition °iake room for the image 420. If the image is being placed 

300. This may include all of the user data 614 or it may in an image contairier, the container contents may need to be 

include selected user data, such as selected files and/or moved and/or modified. As noted, this space may be located 

subdirectories. Familiar file and subdirectory selection tools at one end of the partition to aid the image locator 620. If file 

and techniques such as wild cards, dialog boxes, and the like system data is kept at one end of the partition, as m FAT 

may be used. The obtaining step 702 may read user data partitions, then the image(s) 420 are placed at the opposite 

direcUy from the partition 300, using standard file system ^° partition. Tools and techniques for relocating 

file-oriented calls or (preferably) lower level sector/cluster- portions of a file without destroying user data are known in 

oriented routines. Tools and techniques for accessing user ^® 

data without going through the file system are well known The subdirectory creating step creates a system and/or 

in the art. Instead of reading user data from locations hidden subdirectory dedicated to holding image(s) 420 or 

organized by the file system, the obtaining step 702 may read the image container 534 and having a special name readily 

a copy of user data from a previously created image 420 of identified by the implementing program. Placing all images 

the partition 300. For instance, one could select an image, 420 in such a subdirectory makes it easier during step 736 

identify files or subdirectories that were stored in that image to avoid overwriting the image(s) 420 which are stored in the 

but will not be stored in a new image, and then create the partition 300 when the data from an image 420 is laid down 

new image. on top of existing partition 300 contents during the restoring 

During a creating step 704, the system creates an **^P ^2^* 

in-partition image 420 by at least storing a copy of at least The data preparing step 714 compresses, packs, and/or 

a portion of the user data from the partition 300 in at least encrypts the user data which is being imaged. These actions 

one image 420 in the same partition 300. The storing step 35 are discussed above in connection with the image creator 

within the creating step 704 includes at least an explicit 618. 

placing step 716 and an implicit or explicit determining step The placing step 716 places the user data in the image, 

708, and optionally includes one or more of a verifying step with the determined characteristics, in the vacated space 

706, a vacating step 710, a subdirectory creating step 712, and/or hidden subdirectory, after verification and data prepa- 

and a data preparing step 714, Which steps are required 4Q ration. The specific act of creating an image 420 may be 

depends on the appended claims, as they are understood by done with familiar tools and techniques, but the use of those 

those of skill in the art. It will also be appreciated that these tools and techniques for in-partition images is novel, 

steps, like others described herein, may generally be per- jhe image 420 must be created when the computer has 

formed in various orders or concurrenUy, may be repeated, been put into a state that allows exclusive disk 606 access, 

and may be renamed or grouped differently in different 45 -This prevents inconsistencies in the data (modification dur- 

embodiments. Each of these steps wUl now be discussed in ing the imaging process) and helps ensure that system 

information such as the Microsoft Windows registry are 

The verifying step 706 verifies the integrity of the file closed (or inaccessible to any other process, for example if 
system data which organizes the user data being placed in running under a variant of the UNIX operating system) and 
the image 420. Note that FIG. 7 shows two additional 50 so can be imaged. Some operating systems provide a lock 
verifying steps, identified as 722 and 732. The three veri- guaranteeing exclusive disk 606 access. On some systems, 
fying steps perform the same general task, which is to detect the implementing program can be run after rebooting to a 
inconsistencies in the data on which the system 600 relies single- threaded operating system such as MS-DOS. On 
and correct them or otherwise prevent image utihzation Systems running Windows NT or Windows 2000, the imple- 
based on the inconsistencies. Each of the verifying steps 55 menting program can be run at subsystem load time before 
706, 722, 732 may use routines or data structures in the virtual memory and multiprocessing subsystems are run- 
image verifier 622 that are also used by one or both of the ning. On systems nmning a variant of UNIX, the imple- 
other verifying steps. menting program can be run in single user (root only login) 

However, the type of data being verified depends on the mode, 

context. Thus, the verifying step 706 verifies file system data 60 A recovery aid making step 718 creates a copy of neces- 

616 to avoid creation of a corrupt image during image sary portions of system data on a removable or other 

creating step 704. The verifying step 722 verifies both file medium which can then be used by the image locator 620 as 

system data 616 and the contents of an image 420 to avoid discussed above to locate the image(s) 420 if some or all of 

cormption of the image during an image updating step 720; the system data is lost. The recovery aid medium could be 

the inputs to the update include both the current version of 65 a diskette, a writable CD, a Zip drive, a tape drive, a remote 

the image 420 and the user data organized by the file system or alternate disk, or another medium which does not contain 

data 616. The verifying step 732 verifies the contents of an the partition 300 that holds the day-to-day working copy of 
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the system data. Note that a recovery aid such as a "rescue Additional Implementation Notes 

diskette" does not itself necessarily contain any images 420. Image Creation 

Rather, it assists the system 600 in locating in-partition One embodiment of the invention creates and writes 
images 420 located on some medium other than the recovery images to a contiguous file in the PowerQuest image con- 
aid medium. 5 tainer format and places the image container 534 at one end 

The recovery aid should hold a subset of the partition of the partition 300. The PowerQuest Drive Image® utility 

system data that allows the image 420 stored within the also uses this image container format. The .pqi and .pqc files 

partition 300 to be recovered. Which system files or other fo^niing the image container 534 may reside in a subdircc- 

data should be saved on Oie recovery aid depends both on the tory which is marked with the system, hidden, and read-only 

file system involved and the nature of t^^ lo directory attributes. Ihis helps prevent image files and 

mstance If the miage 420 is stored ma non^ontiguo^^^^ ^ containers from accidentally being modified by the 

and the file system environment IS FAT 12, FATl 6 or FAr32, ^ / & / 

then copies of the MBR, boot sector(s) and extensions, FAT ^^l' c ^ • a^^a n i_ . j l .t. 

and the root directory of the partition 300 should be stored ^^""^'l ^^4 will normaUy be created by the 

on the recovery aid medium. If some other file system is f f ^ operatmg system 

used, then the equivalent of these file system structures installed in the computer. A factory image 

should be stored. If the image 420 is stored in a contiguous ^s^MaWy cannot be updated by the user, but some embodi- 

file, then the boot sector (and its offset firom the beginning ^^^^^ ^^low factory image updates, 

of the drive), and root directory (and its offset fi-om the When creating or updating an image 420 the storage size 

beginning of the partition) of the partition 300 or equivalent of the completed image 420 is first estimated. In one 

system data should be stored. If the image 420 is stored 20 implementation, a bitmap which tells the state of each 

contiguously at the end of the partition 300 then only enough cluster (including at least an indication of whether a given 

information to locate the partition 300 end is stored. If the cluster is in use) is created using the file allocation table or 

image 420 is stored non -contiguously then the method used its equivalent. The number of used clusters is then muUiplied 

to store the image 420 should be known lo the program that by the cluster size to approximate the image 420 size. If 

reads the recovery aid copy of die system data. This method 25 compression is to be used, then conservative compression 

may be similar to that used in a FAT table, or it may be a size estimates should also be considered during the estimation, 

and a kst of ofifeets, or some other method might be used to Methods of creating a bitmap of used sectors or clusters are 

hnk the non-coiitiguous pieces of the image 420. As an ^n^^ by those of skill in the art; if the NTFS file system 

alternative, block sequence numbers along >^th unique ^eing used, the existing bitmap 520 can be used, 

miage signature can be Placed m the image fi e(s). Hie 3^ ^^^^^^^^ J^^^^ . ^^O at the end 

recovery process would then link up all blocks of the image ^^rt- .u * 1 i_ r 

Ann ;„ „ i^f^ ™„™^ of the partition 300 is then vacated lo make enough room for 

42U m sequence order to regenerate a complete image. ■^-^ft. l . j i r« . ^ 

• \. J,. . , A^t^ the image 420 to be stored contiguously. The image 420 will 

uurmg me upaating image step 72U, an image 42U often be larger than the maximum file size, which is 2 GB 

previooisly created can be updated o reflect changes such as ^ Accordingly, an image container 420 

changes m the user data (content and/or placement), the 35 ^ ^„ j^^y ^ J 

partiUon 300 size and changes m system data (con ent implementation, the container includes a first file 

and/or placement). In some miplementations, a porUon of an fiiename.pqi, with "filename" specified by the user. 

image 420 may be updated, with the user selecting which ^, . „ . fii * *u * • c^ia u 4 i 

uj*-. A * jcjvfcj. subsequent files m the container 534 have sequential 

files or subdirectories to update or a predefined hst of data ^^^^^ ^^^^ 

may automatically be selected for updating. In other instance, if the user named the image 420 "Mytoage" and 

implementaUons, the entire partition 300 is automaticaUy ^^^^ ^^^^ ^^^^^^ ^^^^^ ^ 420, then Fhe files 

coped over the image 420 being updated. ^ container would be named Mylmage.pqi, 

Durmg the venfymg step 722 the rehabihty of the data to Mylmage.OOl, and Mylmage.002. Other naming conven- 

be imaged is checked, llie image 420 being updated may be ^^^^ ^e used. In addition, the contamer may 

verified at least before the update, after the update, or at both 45 ^^^^^^ ^^^^^^y fij^s to aid in recovery consisting of 

times. Likewise, the other venfying steps may be perf^^^ toc_begin.pqc, image files, inter<n>.pqc files between 

before after or both before and after the image utihzmg ij^^ge files, and a toc_end.pqc file at the end of the 

steps 716 and 734. container. The contents of tiiese files have been discussed 

A locating step 726 locates one or more images 420 which above, 

may subsequently be updated during step 720 or used for 50 When a subdirectory dedicated to images 420 does not 

restoration during step 728. Image 420 location was dis- exist, one is made using standard file system directory 

cussed above in connection with the image locator 620. creation and attribute-setting calls, or their equivalent in 

An image 420 is restored during the restoring step 728. If terms of direct manipulation of file system data. If space for 

multiple images 420 of the partition 300 are stored in the the dedicated subdirectory is not at the end of the partition 

partition 300, the implementing program or a user selects a 5s 300, then the data stored there can be vacated to make room 

particular image 420 to be restored during a selecting step for Uie subdirectory of images 420. Alternatively, if enough 

730. For instance, the most recent user-generated image 422 contiguous space is not available, Uie user may be informed 

could be the default selection when several images 420 are that there is insufficient space and the program exits or the 

present. The verifying step 732 proceeds as discussed above. image 420 is stored non-contiguously. 

Tlie copying step 734 proceeds generally as in standard 60 The bitmap generation is modified to exclude both the 

image restoration tools, so restoring the image will also image 420 that will be created and its file stmcture, as the 

restore any damaged system files, lost device drivers, and image 420 is generally not stored within itself. If the NT file 

like data which is not protected by the approach illustrated system or another file system that provides a bitmap auto- 

in FIG. 1. In some embodiments the copying step 734 is matically is being used, the copy of the bitmap file 520 is 

coordinated with an avoiding step 736 to prevent image 65 altered. Depending on how the image 420 is stored, this may 

restoration from overwriting images 420 stored in the target involve including or excluding a single file (if the image 420 

partition 300. is stored in a single file), an entire subdirectory (if the image 
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420 is stored in a single subdirectory), or a list of files (if the Once the location of the image 420 is known, the data 

image 420 is stored as a series of files in a container). The integrity should be verified; if problems are discovered, then 

modified bitmap indicates which clusters or sectors are free the user is notified, and the process will end. Otherwise, one 

and which are allocated in the partition 300 outside of the implementation then compares a bitmap stored in the image 

image 420. The image files themselves are listed as unallo- S 420 with the bitmap that contains the .pqi files to ensure that 

cated space to avoid imaging them. the restore operation will not overwrite the existing image 

After creation of an image 420, directory entries in the ( pqi) files. One implementation saves in memory all image 

root directory or equivalent file system structure should be file system information, such as cluster chains and directory 

updated to reflect the new image 420 including the image's entries, and then adds that file system information to the 

file(s) and/or subdirectory. The FAT 410 or equivalent struc- 10 restored image, thereby ensuring that the imag6(s) are 

ture is also updated. known to the file system in the partition 300 after the restore. 

To optimize disk head movement, image files can be The size of the current partition 300 is checked to ensure that 

allocated in reverse cluster order based on reasonable block it is large enough to hold the restored image 420. If the 

size. All cluster allocations should, if possible, be made in partition 300 is too small, the restore should not be per- 

memory so the FAT 410 or equivalent structure(s) can be 15 formed. 

flushed to disk 606 after the image has been built. Internal Next, the image 420 is used to restore the original 

storage of block location varies by implementation, but partition information. The image 420 itself is not stored 

locations may be stored in the bitmap or in a run hst. within the image 420, and so the copy of the image 420 on 

Image Restoration the medium 606 should be protected as discussed above 

To begin restoration, one implementing program checks 20 while the image contents are being written to that medium 

to see if the system 600 is bootable, by virtue of a bootable 606 outside the on-disk image file or image container. The 

hard drive partition, a bootable floppy, or downloadable position of the image (.pqi) file(s) should be checked. If the 

operating system available over a network, for instance. If it image 420 is not contiguous and at the end of the partition 

is, the implementing program tries to locate (image locator 300, then the image may be moved to that contiguous 

620) at least one image 420, If no image 420 is found, the 25 location before the restore begins. If both a user image 422 

program returns an error. If more than one image 420 is and a factory image 424 exist, the factory image 424 may be 

found, the program returns the names of all images. All the last one in the partition 300. 

operations should be designed to be halted between any of If the image 420 is stored in a contiguous file or container, 

the steps without causing damage to the image 420. then the factory image 424 may be created as a "master" 

If the system is not bootable from a bootable hard drive 30 image on a smaller drive and then cloned to a larger drive, 

partition, then the restoration involves booting from a rescue For example, the image 420 may be created on a 4 Gb drive 

diskette that contains the boot files and a recovery applica- and then be cloned to a 20 Gb drive. The cloned image 420 

tion. If critical system data is intact, then image recovery in the larger, cloned partition will not necessarily be at the 

proceeds. Critical system data generally includes the parti- end of the partition. In some implementations, the cloned 

tion table, the boot record, the FAT or equivalent, and the 35 image 420 is then moved to the end of the partition; in others 

directory. it is left in its original location. 

A more difficult situation exists when the system data on If the image 420 is at the physical end of the drive 606 and 

the persistent storage 606 is damaged. This occurs when the is stored either as a file or as a series of files in a container, 

partition table is damaged, the boot record is damaged, the then at least some hardware disk rephcators will duplicate 

drive has been reformatted, the FAT is damaged, and/or the 40 the entire drive 606. If this is not desired, the image 420 can 

root directory is damaged. One implementation recovers be stored closer to the front of the drive 606. 

data by enabling a key instruction sequence at start-up that One implementation places the contiguous image at the 

will look for a boot-up sequence to automatically boot the end of the partition. This location is then marked. The 

machine and start the recovery process. For this to occur, the implementation also creates a separate partition 612 which 

"rescue diskette" executable code and the restore application 45 contains access and validity information for the image(s). 

should previously have been placed at a known location on For instance, this partition 612 may contain a file index 

the partition 606. giving the name(s) of the image file(s) and their physical 

Another method for catastrophic disk recovery is to place location(s) on the disk, and the information as defined in the 
key partition files such as image file names, locations, and container file for signatures and checksums. Placing the 
other key information in a diagnostic and recovery partition 50 image 420 as a contiguous block at the end of the partition 
612. This diagnostic and recovery partition 612 may be a 300 offers some protection in the event of a head crash, as 
"one cylinder" primary partition which contains the file crashes more commonly occur at the beginning of a parti- 
names, run lists, checksums, cluster run information, and tion. Likewise, a head crash is less likely to damage data in 
other information required for recovery. If diagnostic and the partition 612 because the head is less frequently over that 
recovery partition 612 is used, a check should be performed 55 data. 

(when booting or otherwise) to ensure that the image loca- A disadvantage is that the partition 612 counts as one of 

tions are synchronized with the diagnostic and recovery the four permitted primary partitions. This is an issue if the 

partition 612 information. Furthermore, checksum informa- user wants to create multiple bootable partitions and reaches 

tion should be stored in the .pqi file(s) for verification during the four partition limit. For example, this may be an issue 

disaster recovery. Using this method, images 420 can be 60 with LINUX and its use of swap partitions. However, to 

restored even after a partition table has been modified with ameUorate this problem, LINUX (and other operating sys- 

the FDISK tool, and even when partition system information tems such as Windows NT) can boot from an extended 

stored in the partition table, the boot record, the FAT or partition. 

Master File Table, and/or the root directory has been dam- An image 420 can be written as one or more files utiUzing 

aged. Of course, physical damage to the storage medium 606 65 the file system structures. Thus, writing the image 420 to 

itself may prevent recovery even when the diagnostic and disk and allocating space for it is handled by the file system, 

recovery partition 612 is used. If the file is firagmented, even if marked hidden/system, the 
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file system itself handles all implementation details. It may 
be more difficult to recover the image 420 if the file system 
data is damaged, but this problem can be avoided by using 
a recovery aid, as discussed above. Extra care must also be 
taken to modify the imaging process so the image file itself 
is not imaged. Also, confusion may arise during recovery 
because of the existence of extraneous "old** blocks of data 
on the disk that previously beloaged to other, currently 
invalid images, so care must be taken to ensure that the 
clusters read belong to the correct image. This is possible if 
the header information discussed above is implemented 
within the blocks. 

SUMMARY 

In summary, the present invention provides systems and 
methods for using an image of a partition within the partition 
being imaged. The image contents can be recovered in at 
least most cases even if the system files such as the File 
Allocation Table, NTFS run information, or UNIX inode 
information is lost through a drive failure, virus attack, user 
error, or other event. 

Articles of manufacture within the scope of the present 
invention include a computer-readable storage medium in 
combination with the specific physical configuration of a 
substrate of the computer- readable storage medium. The 
substrate configuration represents data and instructions 
which cause the computers to operate in a specific and 
predefined manner as described herein. Suitable storage 
devices include floppy disks, hard disks, tape, GD-ROMs, 
DVD devices, RAM, and other media readable by one or 
more of the computers. Each such medium tangibly embod- 
ies a program, functions, and/or instructions that are execut- 
able by the machines to perform imaging and image usage 
steps with images that have been or arc being stored in the 
imaged partition, substantially as described herein. 

Although particular methods and embodying the present 
invention are expressly ill;istrated and described herein, it 
will be appreciated that system and configured storage 
medium embodiments may be formed according to the 
methods of the present invention. Unless otherwise 
expressly indicted, the descriptions herein of methods of the 
present invention therefore extend to corresponding systems 
and configured storage media, and the descriptions of sys- 
tems and configured storage media of the present invention 
extend likewise to corresponding methods. 

In addition, the method steps discussed may be performed 
in various orders, except in those cases in which the resuUs 
of one step are required as input to another step. Likewise, 
steps may be omitted unless called for in issued claims, 
regardless of whether they are expressly described as 
optional in this Detailed Description. Steps may also be 
repeated, or combined, or named differently. 

As used herein, terms such as "a" and "the" and item 
designations such as "image" are inclusive of one or more of 
the indicated item. In particular, in the claims a reference to 
an item means at least one such item is required. When 
exactly one item is intended, this document will slate that 
requirement expressly. 

The invention may be embodied in other specific forms 
without departing from its essential characteristics. The 
described embodiments are to be considered in all respects 
only as illustrative and not restrictive. Headings are for 
convenience only. The scope of the invention is, therefore, 
indicated by the appended claims rather than by the fore- 
going description. All changes which come within the mean- 
ing and range of equivalency of the claims are to be 
embraced within their scope. 

What is claimed and desired to be secured by patent is: 

1. A computer system comprising: 
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a processor, a volatile memory in operable connection 

with the processor, and a persistent storage medium 

accessible to the processor; 
a partition stored in the persistent storage; 
5 user data stored in the partition; 

file system data stored in the partition; and 

at least one image which contains a copy of at least a 

portion of the user data, the image also being stored in 

the partition. 

10 2. The system of claim 1, wherein the partition is defined 
by an IBM-compatible partition table. 

3. The system of claim 1, wherein the image also contains 
a copy of at least a portion of the system data, 

4. The system of claim 1, further comprising an image 
restorer which uses the image to restore user data. 

5. The system of claim 4, wherein the restorer restores the 
user data to a destination that is within the same partition as 
the image. 

6. The system of claim 4, wherein the restorer restores the 
user data to a destination that is outside the partition that 

20 contains the image. 

7. The system of claim 4, wherein the system further 
comprises an image locator which uses system data to locate 
the image within the partition. 

8. The system of claim 7, wherein multiple images are 
stored in the partition and the image locator locates a specific 
image from which the image restorer can restore user data, 

9. The system of claim 7, wherein the image locator uses 
system data read from a removable persistent storage 
medium. 

10. The system of claim 7, wherein the image locator uses 
30 system data read from a fixed location in the partition. 

11. The system of claim 7, wherein the image locator uses 
system data read from a different partition than the partition 
that contains the image. 

12. The system of claim 7, wherein the image locator uses 
35 system data read from an image container. 

13. The system of claim 12, wherein the different partition 
is a diagnostic and recovery partition. 

14. ITie system of claim 7, wherein the system data 
includes file system data, 

15. The system of claim 14, wherein the system data 
^° includes a copy of the partition table and the image restorer 

restores the image when the copied partition table is dam- 
aged. 

16. The system of claim 14, wherein the system data 
includes a copy of the boot record and the image restorer 

45 restores the image when the copied boot record is damaged. 

17. The system of claim 14, wherein the system data 
includes a copy of a file allocation table and the image 
restorer restores the unage when the copied file allocation 
table is damaged. 

50 18. The system of claim 14, wherein the system data 
includes a copy of a master file table and the image restorer 
restores the image when the copied master file table is 
damaged. 

19. The system of claim 14, wherein the system data 
includes a copy of inode information and the image restorer 
restores the image when the copied inode information is 
damaged, 

20. The system of claim 1, further comprising an image 
verifier which verifies the integrity of the image. 

21. The system of claim 1, further comprising an image 
creator which creates an image of at least a portion of the 
user data and stores the created image within the partition. 

22. The system of claim 1, wherein at least one image 
within the partition is an end-user image, 

23. The system of claim 1, wherein at least one image 
65 within the partition is a factory image. 

24. The system of claim 1, wherein at least one image 
within the partition is an incremental image. 
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25. The system of claim 24, wherein ibe incremenlal 
image is incremental with respect to a factory image. 

26. The system of claim 1, oomprising at least two images 
stored in the partition, one of the images being a user image 
and another of the images being a factory image. 

27. The system of claim 1, wherein the image is stored 
contiguously. 

28. The system of claim 1, wherein the image is stored at 
one end of the partition. 

29. The system of claim 1, wherein the image is stored as 
a file. 

30. The system of claim 1, wherein the image is one of at 
least one image that is stored in an image container. 

31. The system of claim 1, wherein the file system data 
includes FAT file system data. 

32. The system of claim 1, wherein the file system data 
inchides NTFS file system data. 

33. The system of claim 1, wherein the file system data 
includes file system data of a UNIX-like file system. 

34. A method of utilizing a partition within a computer 
system, the method comprising the computer-aided steps of: 

obtaining a copy of user data which is stored in the 
partition; and 

creating an in -partition image by at least storing a copy of 
at least a portion of the user data in at least one image 
in the same partition. 

35. The method of claim 34, wherein the method com- 
prises reading an IBM-compatible partition table. 

36. The method of claim 34, wherein the obtaining step 
comprises reading user data directly from the partition. 

37. The method of claim 34, wherein the obtaining step 
comprises reading user data from a previously created image 
of the partition. 

38. The method of claim 34, wherein the creating step 
creates an in-partition factory image of the partition, 

39. The method of claim 34, wherein the creating step 
creates an in-partition user-generated image of the partition. 

40. The method of claim 39, further comprising the step 
of updating the user-generated image within the partition. 

41. The method of claim 39, wherein the creating step 
comprises vacating the end of the partition to make room for 
the user-generated image of the partition. 

42. The method of claim 34, wherein the storing step 
comprises storing an image of the partition in a subdirectory 
of the partition which is dedicated for holding at least one 
image of the partition, 

43. Hie method of claim 34, further comprising the 
computer-aided steps of reading system data which is stored 
in the partition, and storing a copy of at least a portion of the 
system data in the image in the partition. 

44. The method of claim 34, further comprising the 
computer-aided steps of reading system data which is stored 
in the partition, and storing a copy of at least a portion of the 
system data outside the partition. 

45. The method of claim 34, wherein the storing step 
comprises storing an image of the partition in a file in the 
partition. 

46. The method of claim 34, wherein the storing step 
comprises storing an image of the partition in an image 
container in the partition. 

47. Hie method of claim 34, wherein the storing step 
comprises storing an image of the partition contiguously in 
the partition. 

48. The method of claim 34, wherein the storing step 
comprises storing an image of the partition non- 
contiguously in the partition. 

49. The method of claim 34, further comprising the step 
of restoring selected user data using the image. 

50. A computer program storage medium having a con- 
figuration that represents data and instructions which will 
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cause at least a portion of a computer system to perform 
method steps for utiUzing a partition within a computer 
system, the method steps comprising the steps of locating an 
image of the partition which is stored in the partition, and 
s restoring selected user data from the image to the partition. 

51. The configured program storage medium of claim 50, 
wherein the partition is a bootable primary partition. 

52. The configured program storage medium of claim 50, 
wherein the method further comprises the step of verifying 

10 the consistency and integrity of the image before the restor- 
ing step. 

53. The configured program storage medium of claim 50, 
wherein the method further comprises the step of verifying 
the consistency and integrity of the image after the restoring 

15 step. 

54. The configured program storage medium of claim 50, 
wherein the locating step locates the image in an image 
container, and the restoring step restores user data from the 
image despite damage to the image container. 

20 55. The configured program storage medium of claim 50, 
wherein the locating step locates the image among at least 
two images in an image container, and the restoring step 
restores user data from the image despite damage to another 
image in the image container. 

25 56. The configured program storage medium of claim 50, 
wherein the restoring step restores user data to the partition 
&om the image stored in the partition without overwriting 
the image, 

57. The configured program storage medium of claim 50, 
30 wherein the method further comprises the step of making a 

recovery aid by copying selected system data onto a remov- 
able persistent storage medium, and the locating step uses 
the recovery aid to locate the image. 

58. The configured program storage medium of claim 57, 
35 wherein the locating step uses the recovery aid to obtain a 

copy of a partition table identifying the partition. 

59. The configured program storage medium of claim 57, 
wherein the locating step uses the recovery aid to obtain a 
copy of file system data for the partition. 

60. A configured medium comprising a persistent 
*° computer-readable storage medium, an imaged partition 

containing aser data and a partition image including at least 
a portion of the user data, the configured medium further 
characterized in that the partition image is stored within the 
imaged partition on the persistent computer-readable storage 
45 medium. 

61. The configured medium of claim 60, wherein the 
partition image is stored within a dedicated subdirectory of 
the imaged partition. 

62. The configured medium of claim 60, wherein the 
50 partition image is stored at an end of the imaged partition. 

63. The configured medium of claim 60, wherein the 
partition image is stored within an image container. 

64. The configured medium of claim 63, wherein the 
image container also contains a copy of file system data. 

55 65. The configured medium of claim 60, further compris- 
ing at least one additional partition image which is also 
stored in the imaged partition. 

66. The configured medium of claim 60, wherein the 
imaged partition includes FAT file system data organizing 
the user data. 

67. The configured medium of claim 60, wherein the 
imaged partition includes NTFS file system data organizing 
the user data. 

68. The configured medium of claim 60, wherein the 
imaged partition includes UNIX-like file system data orga- 

65 nizing the user data. 

♦ ♦ ♦ ♦ ♦ 
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